The present invention relates to an interface between an application program and various models of hardware, and more particularly relates to an interface between a switch adapter and a communications subsystem in a data processing system.
The IBM Scalable POWERparallel (SP) system is a distributed parallel data processing system that incorporates a central switch which provides a high efficiency interconnection of processor nodes. There are several versions of SP switches and switch-adapters (which connect processors to switches). The existing SP communications protocol software has unique adapter dependent software for each adapter type and different protocols have adapter specific software which is different between protocols for the adapter type. With each new switch-adapter, each of the protocol software functions is modified to provide support for the new adapter device. Currently there are N (three) communication protocol functions (Internet Protocol (IP), Message Passing Interface protocol (MPI), Service), and each is separately modified to support a single adapter type and each has M versions of adapter device interfaces which they support. The development and support bill for the SP communications software is N.times.M. In the near future there are new communications protocols (e.g., Low-level Application Programming Interface (LAPI)) and several new switch adapters planned for the SP. So continuing the current protocol structure results in the continued escalation of the N.times.M multiplier! A further restriction in today's system is that all tasks within a parallel job must be connected to the same device type (e.g., all IP, all TB3).
In addition to providing a common interface solution for the current environment described above, there needs to be support for dynamic tasking (parallel job size can shrink and/or grow during run time) and multiple communication channel protocol support (e.g., a parallel job running some tasks on an SP connected via switch path and some tasks running on stand-alone workstations connected via IP/token-ring).
A third problem needing to be solved is the requirement to provide low latency asynchronous notification, efficient data movement, and low overhead device management.